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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

Please note that the present document is a revision to TR 102 542 [i.l], and has been converted to a Technical 
Specification (TS) because the language used in the document is akin to that of a Technical Specification (TS). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1 21 8 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

The Digital Video Broadcasting Project (DVB) is an industry-led consortium of broadcasters, manufacturers, network 
operators, software developers, regulatory bodies, content owners and others committed to designing global standards 
for the delivery of digital television and data services. DVB fosters market driven solutions that meet the needs and 
economic circumstances of broadcast industry stakeholders and consumers. DVB standards cover all aspects of digital 
television from transmission through interfacing, conditional access and interactivity for digital video, audio and data. 
The consortium came together in 1993 to provide global standardisation, interoperability and future proof 
specifications. 

The present document is part 2 of a multi-part deliverable. Full details of the entire series can be found in part 1, 
TS 102 542-1 [9]. 
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Scope 



The present document is designed as a companion document to help implement the DVB-IPTV Phase 1 version 4; 
Transport of MPEG2-TS Based DVB Services over IP Based Networks [1], which is referred to as the Handbook. 

The present document deals with Broadband Content Guide (BCG) and Content on Demand. It presents the ways to 
discover BCG and Content on Demand, and how to connect to them. The present document is organized in separate 
sections in the order of the boot-up sequence of the HNED rather than in the same section structure as the Handbook. 
Each clause deals with a specific aspect of the DVB-IPTV technology, and offers explanations and examples not found 
in the Handbook. Additionally, it provides guidelines to implement the Broadband Content Guide (BCG) 
specification [3]. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 102 034 (Vl.4.1): "Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based 

DVB Services over IP Based Networks". 

[2] ETSI TS 101 154 (Vl.8.1): "Digital Video Broadcasting (DVB); Specification for the use of Video 

and Audio Coding in Broadcasting Applications based on the MPEG-2 Transport Stream". 

[3] ETSI TS 102 539 (Vl.2.1): "Digital Video Broadcasting (DVB); Carriage of Broadband Content 

Guide (BCG) information over Internet Protocol (IP)". 

[4] ETSI TS 102 822-2 (VI. 3.1): "Broadcast and On-line Services: Search, select, and rightful use of 

content on personal storage systems ("TV-Anytime"); Part 2: System description". 

[5] ETSI TS 102 822-3-2 (Vl.3.1): "Broadcast and On-line Services: Search, select, and rightful use 

of content on personal storage systems ("TV-Anytime"); Part 3: Metadata; Sub-part 2: System 
aspects in a uni-directional environment". 

[6] ETSI TS 102 822-4 (Vl.2.1): "Broadcast and On-line Services: Search, select, and rightful use of 

content on personal storage systems ("TV-Anytime"); Part 4: Content referencing". 
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[7] 

[8] 
[9] 



ETSI TS 102 822-6-1 (Vl.3.1): "Broadcast and On-line Services: Search, select, and rightful use 
of content on personal storage systems ("TV-Anytime"); Part 6: Delivery of metadata over a 
bi-directional network; Sub-part 1: Service and transport". 

ETSI TS 102 323: "Digital Video Broadcasting (DVB); Carriage and signalUng of TV-Anytime 
information in DVB transport streams". 

ETSI TS 102 542-1: "Digital Video Broadcasting (DVB); Guidelines for the implementation of 
DVB-IPTV Phase 1 specifications; Part 1: Core IPTV Functions". 



2.2 



Informative references 



The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 



[i.l] 



ETSI TR 102 542: "Digital Video Broadcasting (DVB); GuideUnes for DVB IP Phase 1 
Handbook". 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

BCG Broadband Content Guide 

BiM Binary MPEG Format for XML 

CRI Content Reference Information 

CRID Content Reference Identifier 

DVB Digital Video Broadcasting 

DVBSTP DVB SD&S Transport Protocol 

FEC Forward Error Correction 

HNED Home Network End Device 

HTTP Hyper Text Transfer Protocol 

IGMP Internet Group Management Protocol 

IP Internet Protocol 

IPTV IP Television 

MPEG Moving Picture Experts Group 

MPTS Multi Program Transport Stream 

RAR Resolving Authority Record 

RET RETransmission 

RNT RAR Notification Table 

RTP Real-time Transport Protocol 

RTSP Real Time Streaming Protocol 

SD&S Service Discovery and Selection 

SOAP Simple Object Access Protocol 

SPTS Single Program Transport Stream 

TCP Transmission Control Protocol 

TLS Transaction Layer Security 

TS Transport Stream 

UDP User Datagram Protocol 

URL Uniform Resource Locator 

XML extensible Markup Language 
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BCG Information Discovery 



This clause explains how an HNED can get access to Broadband Content Guide (BCG) descriptions. BCG data are 
TV-Anytime content guide descriptions, which are available on a given always-on bidirectional IP network. 



4.1 Discovery of BCG Providers 



Available BCG providers are discovered through the BCGDiscovery records in the SD&S information, as shown in the 
following example. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb : metadata : iptv: sdns : 2008-1" 
xmlns :xsi="http : //www.w3 . org/2 01/XMLSchema- instance" > 
<BCGDiscovery DomainName="bcgproviderl . com" > 
<BCG Id="bcgl"> 

<Name Language="eng" >Providerl BCG1</Name> 
<TransportMode > 

<HTTP Location= "beg. provider 1 . com/dvb/sdns/" > 
<PayloadId Id="al"> 

<Segment ID="7b" Version="4"/> 
<Segment ID="4d5" Version="17"/> 
<Segment ID="1" Version="2"/> 
</PayloadId> 
<PayloadId Id="a2"> 

<Segment ID="0" Version="4"/> 
</PayloadId> 
<PayloadId Id="a3"> 

<Segment ID="0"/> 
</PayloadId> 
<PayloadId Id="a4"> 

<Segment ID="87" Version="71"/> 
</PayloadId> 
<PayloadId Id="a5"> 

<Segment ID="4"/> 
</PayloadId> 
<PayloadId Id="a6"> 

<Segment ID="42"/> 
</PayloadId> 
<PayloadId Id="a7"> 

<Segment ID="l"/> 
</PayloadId> 
</HTTP> 

<DVBSTP Port="8207" Address="224 . 222 . 2 . 46 " /> 

<HTTP Location="bcg. soap .providerl . com/dvb/sdns/" SOAP="true" /> 
< /TransportMode > 

<TargetProvider>sport .providerl . com</TargetProvider> 
</BCG> 
<BCG Id="bcg2"> 

<Name Language="eng" >Providerl BCG2</Name> 
<TransportMode > 

<DVBSTP Port="5512" Address="224 . 235 . 32 . 4 " /> 
< /TransportMode > 

<TargetProvider>news .providerl . com</TargetProvider> 
</BCG> 
< /BCGDiscovery > 
</ServiceDiscovery> 

The previous example provides BCG discovery information for "Providerl" and "Provider2". The BCGl provides 
content guide for content provider "sport-provider.com", and is transmitted over DVBSTP or HTTP. In the case of 
HTTP, all Payloadlds are identified, with their segment (and optionally their version). Furthermore, the BCGl 
advertises a SOAP server. The BCG2 is only retrievable via DVBSTP. 

If multiple BCG records are available then one may be specified as preferred in the ServicesDescriptionLocation, 
otherwise the choice is implementation dependent e.g. it may be based on user preference. 

Note that updated versions of BCG records can be detected by the terminal using the same mechanisms as for SD&S 
records, i.e. using the version field in DVBSTP header in the case of DVBSTP and the VersionN umber field in the URL 
for the HTTP request in the case of HTTP. 
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4.2 Access to BCG Information 

Access to BCG Information from a BCG provider is done in Push or Pull mode, and optionally using SOAP Queries. 

4.2.1 DVBSTP and HTTP Mechanisms 

For Push mode and HTTP Pull mode, BCG data are made available to HNEDs as BiM-encoded TV-Anytime fragments 
encapsulated in containers, as specified in TS 102 323 [8]. They can be transported in Push mode over DVBSTP or in 
Pull mode over HTTP. 

4.2.1 .1 Typical Flow Of Events 

The following steps outline a typical flow of events from SD&S record via BCG to content acquisition if using the 
container-based delivery mechanism: 

• Acquire BCG Discovery record(s) via SD&S. 

• Select or choose the BCG provider and delivery mechanism to receive BCG information. 

• Receive TV-Anytime metadata container: 

Initialize the BiM decoder: 

Get the DVB-TV A-init. An example DVB-TVA-init message can be found in TS 102 323 [8], 
annex C. 

■ Get the TVAMain fragment, if the TV AMain fragment is not delivered use the default one as 
defined in table 53 of TS 102 323 [8]. 

Receive TV-Anytime metadata index container, if delivered. 

Receive either all or required TV-Anytime metadata data container. 

Present content information to user. 

• User selects content for acquisition, e.g. recording: 

In TV-Anytime content is referenced by the Content Reference Identifier (CRID). 

• Use TV-Anytime content resolution to discover actual content location, see also clause 5 of TS 102 539 [3]: 

Receive the Resolution Provider Notification Table (RNT). 

Check RNT if it contains the suitable Resolving Authority Records (RAR) for the CRID. 

Receive Content Reference Information (CRI structures). 

Resolve CRID into content locator(s). 

4.2.1.2 Example 

The example in this clause provides some guidelines on the usage of the different BCG payload types using the 
container-based delivery mechanism. Table 4.1 from TS 102 539 [3] shows the various payload types composing the 
BCG. 



£75/ 



9 ETSI TS 1 02 542-2 V1 .3.1 (201 0-01 ) 

Table 4.1 



Payload ID value 


Payload type carried 


OxAl 


DVB-TVA-init message (clause 7.3 of TS 102 539 [3]) 


0xA2 


TVAMain fragment (clause 7.4 of TS 1 02 539 [3]) 


0xA3 


TV-Anytime metadata data container (clause 9.2.2 of TS 102 323 [8]), value 'd' in Table 
47) 


0xA4 


TV-Anytime metadata index container (clause 9.2.2 of TS 102 323 [8], value '1' in Table 
47) 


0xA5 


Both TV-Anytime metadata data and index container (clause 9.2.2 of TS 102 323 [8], 
value "b" in table 47) 


0xA6 


RNT (clause 5.1 of TS 102 539 [3])) 


0xA7 


CRI structure (clause 5.3 of TS 102 539 [3]) 


0xA8-0xAF 


Reserved 



The following TV-Anytime metadata document belongs to a broadcast service provider. 



<?xml version="l . 0" encoding="UTF-8" ?> 

<tva : TVAMain xml : lang="eng" xmlns : tva="urn: tva : metadata : 2 005" 
xmlns :xsi="http : //www.w3 . org/2 01/XMLSchema- instance" > 
<tva : ProgramDescription> 

<tva : Programinf ormationTable> 

<tva : Programinf ormat ion programId="crid: //cridauth. com/A" f ragmentld="10 0" > 
<tva : BasicDescription> 

<tva:Title>Sport Program l</tva :Title> 

<tva : Synopsis length= " short " >This is the synopsis of a sport programme</tva : Synopsis> 
<tva:Duration>P0DT01H30M</tva:Duration> 
</tva : BasicDescription> 
</tva : Programinf ormation> 

<tva : Programinf ormat ion programId="crid: //cridauth. com/B" f ragmentld="101" > 
<tva : BasicDescription> 

<tva:Title>Sport Program 2</tva :Title> 

<tva : Synopsis length= " short " >This is the synopsis of another sport program</tva : Synopsis> 
<tva:Duration>P0DT01H30M</tva:Duration> 
</tva :BasicDescription> 
</tva : Programinf ormation> 

<tva : Programinf ormat ion programId="crid: //cridauth. com/C" f ragmentld="102" > 
<tva : BasicDescription> 

<tva:Title>Movie l</tva :Title> 

<tva : Synopsis length= " short " >This is the synopsis of a movie</tva : Synopsis> 
<tva:Duration>P0DT01H30M</tva:Duration> 
</tva : BasicDescription> 

<tva lEpisodeOf crid="crid: //cridauth. com/aseries"/> 
</tva : Programinf ormation> 

<tva : Programinf ormat ion programId="crid: //cridauth. com/D" f ragmentld="103" > 
<tva : BasicDescription> 

<tva:Title>Movie 2</tva :Title> 

<tva : Synopsis length= " short " >This is the synopsis of another movie</tva : Synopsis> 
<tva:Duration>P0DT01H30M</tva:Duration> 
</tva : BasicDescription> 

<tva : EpisodeOf crid="crid: //cridauth. com/aseries"/> 
</tva : Programinf ormation> 
</tva : Programinf ormationTable> 
<tva : Groupinf ormationTable> 

<tva : Groupinf ormat ion groupId="crid: //cridauth. com/aseries" f ragmentld="501"> 
<tva iGroupType xsi : type="tva : ProgramGroupTypeType" value=" series" /> 
<tva : BasicDescription> 

<tva:Title>A series</tva :Title> 
</tva :BasicDescription> 
</tva : Groupinf ormation> 
</tva : Groupinf ormationTable> 
<tva : ProgramLocationTable> 

<tva: Schedule serviceIDRef="asport channel .aprovider.com" start="2005-ll-llT07 :00:00+00:00" 
end="2005-ll-llT10 :00:00+00:00" f ragmentld=" 150 " > 
<tva : ScheduleEvent> 

<tva : Program crid="crid: //cridauth. com/A" /> 

<tva:PublishedStartTime>2005-ll-llT07 : 00 : OOZ</tva : PublishedStartTime> 
<tva : PublishedDuration>P0DT01H30M</tva : PublishedDuration> 
</tva : ScheduleEvent> 
<tva : ScheduleEvent> 

<tva : Program crid="crid: //cridauth. com/B" /> 

<tva:PublishedStartTime>2005-ll-llT08 : 30 : OOZ</tva : PublishedStartTime> 
<tva : PublishedDuration>P0DT01H30M</tva : PublishedDuration> 
</tva : ScheduleEvent> 
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</tva : Schedule> 

<tva: Schedule servicelDRef = "amoviechannel .aprovider.com" start="2005-ll-llT20 :00:00 + 00:00'' 
end="2005-ll-llT23 :00:00+00:00" f ragmentld=" 151" > 
<tva : ScheduleEvent> 

<tva : Program crid="crid: //cridauth. com/C"/> 

<tva:PublishedStartTime>2005-ll-llT20 : 00 : OOZ</tva: PublishedStartTime> 
<tva : PublishedDuration>P0DT01H30M</tva : PublishedDuration> 
</tva : ScheduleEvent> 
<tva : ScheduleEvent> 

<tva : Program crid="crid: //cridauth. com/D"/> 

<tva:PublishedStartTime>2005-ll-llT21 :30 : OOZ</tva : PublishedStartTime> 
<tva : PublishedDuration>P0DT01H30M</tva : PublishedDuration> 
</tva : ScheduleEvent> 
</tva : Schedule> 
</tva : ProgramLocationTable> 
<tva : Serviceinf ormationTable> 

<tva : Serviceinf ormation serviceId="asportchannel . aprovider . com" f ragmentld="200" > 

<tva:Name>A sport channel</tva :Name> 
</tva : Serviceinf ormation> 
<tva : Serviceinf ormation serviceId="amoviechannel . aprovider. com" f ragmentld="201" > 

<tva:Name>A movie channel </ tva : Name > 
</tva : Serviceinf ormation> 
</tva : Serviceinf ormationTable> 
</tva : ProgramDescription> 
</tva:TVAMain> 



The example metadata document contains a Programlnformation and Schedulelnformation fragments for two broadcast 
channels "A Sport Channel" and "A Movie Channel". The programmes on "A Movie Channel" are episodes of a series. 
This series is announced with the Grouplnformation fragment. 

Note that the example also contains a Servicelnformation fragments. Service information like a channel name may also 
be present in the SD&S BroadcastDiscovery record. In that case the HNED shall take the information from BCG 
(TS 102 539 [3] clause 6.6). 

As defined in TS 102 539 [3], TV-Anytime metadata fragments are encoded with BiM and encapsulated in containers. 

NOTE 1: Contrary to TS 102 323 [8], all BCG data is delivered inside a compression wrapper as a data delivery 
unit (TS 102 539 [3], clause 4.1). 

For a real service the amount of metadata will be very large, i.e. the metadata will be delivered in multiple containers. 
Keeping program and schedule information from a single service and day in one container is an example strategy that is 
well suited for most EPG applications. Fragments from the ServicelnformationTable and the GroupInformationTable 
form separate containers in this example. For the metadata document from above this strategy results in a delivery in the 
following three containers: 

Table 4.2 



Container 1 
A Sport Channel -11.11. 


Container 2 
A lUlovie Channel -11.11. 


Container 3 
Service Information 


Fragment 
id 


Fragment Type 


Fragment 
id 


Fragment Type 


Fragment id 


Fragment Type 


100 


Programlnformation 


102 


Programlnformation 


200 


Servicelnformation 


101 


Programlnformation 


103 


Programlnformation 


201 


Servicelnformation 


150 


Schedule 


151 


Schedule 


501 


Grouplnformation 



Receiving and decoding all containers enables the HNED to provide the user with an EPG for all services. Assuming 
the user only wants to know what is on "A Sport Channel", the HNED may scan all containers for the required 
fragments. In a worst case scenario the HNED would have to download and decode all metadata containers. 

A more efficient way in looking for particular metadata fragments can be achieved by using TV-Anytime metadata 
indices as defined by TS 102 323 [8]. Based on TS 102 822-3-2 [5] it provides a set of profiled indices supporting the 
most common usage scenarios. If indices are available the payload id for metadata indices is signalled in the SD&S 
BCG offering record. The index list structure shall be delivered with payload id 0xA4 and segment id 0. 

For the example above it is recommended to add a "Schedule index by time and DVB service". 
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Table 4.3 



Schedule Index by time and DVB Service 


Schedule@end 


Servicelnformation@serviceld 


Container Id 


Fragment Id 


2005-11-11110:00:00+00:00 


asportchannel . aprovider . com 


1 


150 


2005-11-11123:00:00+00:00 


amoviechannel . aprovider . com 


2 


151 



Using this index the HNED can easily determine all containers with schedules for a certain broadcast service and a 
given time window. A schedule fragment usually contains only start time and duration of scheduled programs. The 
description of a program that is contained in a Programlnformation fragment is referenced from a schedule by its 
Content Reference Identifier (CRID). For detailed information on CRIDs refer to TS 102 323 [8], clause 6. A 
"Programlnformation index by CRID" as shown in table 4.4 is recommended to identify containers carrying these 
fragments. 

Table 4.4 



Programlnformation index by CRID 


Programmlnformation@programld 


Container Id 


Fragment Id 


crid://cridauth. com/A 


1 


100 


crid://cridauth.com/B 


1 


101 


crid://cridauth.com/C 


2 


102 


crid://cridauth.com/D 


2 


103 



If Grouplnformation fragments are available as in the example a "Grouplnformation index by CRID" is recommended. 

Up to here this clause describes the usage of TV- Anytime metadata data and indices. The metadata allows announcing 
available conent to the user and it enables the user to search for specific content. 

NOTE 2: For content acquisition the HNED should not use metadata (TS 102 323 [8], clause 8.5). For this purpose 
TV-Anytime proposes the content resolution service. For BCG content resolution is performed as defined 
by TS 102 539 [3], clause 5. For a detailed introduction to content resolution refer to TS 102 822-4 [6]. 

In general content resolution results in the actual locator(s) of a single program or a group of programs. Input to the 
content resolution process is a CRID of either a program described by a Programlnformation fragment or a program 
group described by a Grouplnformation fragment. A CRID of a program usually resolves into locator(s) and a CRID of 
a program group into CRID(s) of programs. However, the CRID of a program may also resolve into other CRJD(s) 
(TS 102 822-4 [6], clause 8 and TS102 323 [8], table 28 note 1). 

A CRID is created and maintained by a CRID authority. The content resolution information (CRI data) for a CRID 
authority is provided by a resolution provider. The Resolution Notification Table (RNT) signals resolution providers 
and CRID authorities. 

Table 4.5 shows the information that is contained in a RNT for signalling a resolution provider who supports the CRID 
authority used in the examples above. 

Table 4.5 



Common Descriptors 


(Empty) 


Resolution Provider Loop 




Provider Name 


aprovider.com 


Descriptors 


(Empty) 


CRID Authority Loop 




Authority Name 


CridAuth.com 


Policy 


CRIDs published by this CRID authority are permanent 


Descriptors 




RAR over IP Descriptor 




First Valid Date 


01.01.2005 00:00 


Last Valid Date 


01.01.2006 00:00 


Weighting 


1 


CompleteFlag 


1 


URL 


(Empty) 
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The policy of the CRID authority is to assign CRIDs permanently to content, i.e. a CRID is never reused for another 
piece of content. The CompleteFlag is set, i.e. the CRI data contains information on all CRIDs provided by the 
resolution provider for the CRID authority (TS 102 323 [8], clause 7.2.3). The empty URL in the RAR over IP 
descriptor indicates that the resolution information is transmitted along with all other BCG containers (TS 102 539 [3], 
clause 5.2), i.e. the CRI data can be found with payload ID 0xA7 using either the pull or push delivery mode as 
signalled in the BCG offering record. The container carrying the cri_index structure has a segment id of 0. 

Table 4.6 shows resolution information for all CRID(s) used in the examples above. 

Table 4.6 



CRID 


Status 


CRID(s) 
Locator(s) 


Acquisition 
directive 


Resolution 
Complete 


Re-Resolution 
Date 


crid://cridauth. com/A 


Resolved 


dvb://1.1.1;AA@2005-11-11... 
dvb://1.2.2;EE@2005-11-10... 


Any 


Yes 


- 


crid://cridauth.com/B 


Resolved 


dvb://1.1.1;BB@2005-11-11... 


Any 


Yes 


- 


crid://cridauth.com/C 


Resolved 


dvb://1 .2.2;CC@2005-1 1 -1 1 ... 


Any 


Yes 


- 


crid://cridauth.com/D 


Resolved 


dvb://1 .2.2;DD@2005-11 -11 ... 


Any 


Yes 


- 


crid ://cridauth .com/aSeries 


Resolved 


crid ://cridauth. com/A 
crid://cridauth.com/B 


All 


No 


2005-11-12 



The resolution of "crid://cridauth.com/A" shows an alternative location of the same content that is broadcasted earlier, 
i.e. the HNED may choose either of the locations for recording. The CRID of the series resolves into two CRIDs of 
programs that could be inferred also from the metadata, but additionally it signals that resolution is not yet complete and 
more episodes will follow. The HNED should perform a new resolution for this CRID on 2005-11-12. 

NOTE: To detect changes of the actual start time of a program the HNED should monitor updates in the CRI 
data. For a detailed description on "Accurate recording" refer to TS 102 539 [3], clause 11. 



4.2.2 SOAP Query Mechanism 



The following clause defines some guidelines for the usage of the BCG SOAP query mechanism. This mechanism is 
used as defined by TV-Anytime in the system specification (TS 102 822-2 [4]) and more specifically in the 
bi-directional specification (TS 102 822-6-1 [7]). As such the ETSI specifications should be referred to for more 
detailed guidelines. 



4.2.2.1 



Typical Flow Of Events 



In order to use the SOAP query mechanism the following steps outline a typical flow of events from SD&S record to 
BCG acquisition: 

Acquire BCG record(s) via SD&S. 

Use the HTTP ©Location URL, where the HTTP® SOAP is "true", to discover the location of a BCG 
provider. 

Send a describe_get_Data SOAP request to the BCG provider. 

Check response to ensure provider has required capabilities. 

Send a get_Data SOAP request to the BCG provider. 

If the capabilities of the BCG providers are not suitable (e.g. a required table is not available) then a describe_get_Data 
may be performed on the next BCG provider until a suitable provider is found. It may be that the data required might be 
stored across a range of BCG providers in which case multiple queries to multiple providers may be required to satisfy a 
particular request. 
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4.2.2.2 Protocol stack 

Figure 4.1 outlines the protocols required to deliver a BCG using the SOAP Query mechanism. 



OPTIONAL --^^ 






TV-AnytimeXML 








SOAP 








binary encoding 






HTTP 








OPTIONAL '"'^^ 
security layer 






TCP 








IP 









Figure 4.1 : BCG over SOAP Protocol Stack 

For further details on the specific usage of SOAP see TS 102 822-6-1 [7], clause 6.1 SOAP. HTTP vl.l shall be 
supported as specified in TS 102 539 [3]. 

As can be seen in figure 4. 1 both encoding and security are optional. For the case of encoding the standard HTTP 
encoding negotiation should be used (Accept-Encoding header). Servers should always support no encoding to ensure 
interoperability. If TLS is used for security, then this can be indicated via the HTTP@Location URL SD&S entry (the 
one with the HTTP@SOAP set to "true"). 

Although security may be used for retrieving metadata it is a particular issue for the submit data method, due to the 
need to ensure privacy of user specific data. In addition, a user should be involved in the decision as to whether to 
enable the submission of either anonymous or user specific data. This can be a trade-off between offering a personalized 
service versus user anonymity. 

The protocols used require that polling be used by a client to check for metadata updates. Selection of the polling 
interval should be tuned to provide a balance between speed of update versus Server load. 



4.2.2.3 



Examples 



The query mechanism contains a large degree of flexibility, thus enabling a BCG client to create either simple or 
complex queries in order to restrict the size of metadata response. The granularity required depends on the application 
and on resource limitations. Therefore a small number of possible request and response examples are provided. 

In all examples the SOAP and HTTP wrappers are omitted for clarity. 

Example 1 is an example response to a describe_get_Data request. The request is not shown as it is simply an empty 
describe_get_Data SOAP method request. The response provides a description of the BCG provider along with its 
capabilities, such as domain, table types and specific fields supported. 
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Example 1 describe_Get_Data response 

<describe_get_Data_Result xmlns="urn: tva : transport : 2005" xmlns : tva="urn: tva : metadata : 2005" 
xmlns :xsi="http : //www.w3 . org/2 01/XMLSchema- instance" serviceVersion="l" > 
<Name>Metadata Service</Name> 

<Description>A metadata service</Description> 
<AuthorityList> 

<Authority>domainl . co .uk< /Authority > 
</AuthorityList> 
<AvailableTables xmlns : tvaf ="urn: tva : transport : f ieldlDs : 2005" > 

<Table xsi : type="ProgramInformationTable" canQuery="tvaf : CRID tvaf : Synopsis tvafiTitle 
tvaf: Keyword tvaf : Genre" /> 

<Table xsi : type="ServiceInformationTable" canQuery=" tvaf : servicelD tvafiName 
tvaf :ServiceURL"/> 

<Table xsi : type="ProgramLocationTable" canQuery= " tvaf : CRID tvaf : servicelDRef tvaf : start 
tvaf: end tvaf : PublishedStartTime tvaf : PublishedDuration" > 
<AvailableLocations> 

<ServiceURL>dvb: //I .1.1. l</ServiceURL> 
< /Aval lableLocat ions > 
</Table> 
</AvailableTables> 
</describe_get_Data_Result> 

Example 2 is an example query and response using the get_Data method. The query requests Programlnformation for 
all programmes with a specific title ("Filml"). The test condition is omitted as equals is the default. 

Example 2: Title Query 

<QueryConstraints> 

<BinaryPredicate f ieldID="tvaf iTitle" f ieldValue="Filml"/> 
</QueryConstraints> 
<RequestedTables> 

<Table type= " Programinf ormat ionTable " / > 
</RequestedTables> 



Example 3: Title Query Response 



<tva iTVAMain xml : lang="eng" xmlns : tva="urn: tva : metadata : 2005" 
xmlns :xsi="http : //www.w3 .org/2 01/XMLSchema- instance" > 
<tva : ProgramDescription> 

<tva : Programinf ormationTable> 

<tva : Programlnformation programId="crid: //123" > 
<tva : BasicDescription> 

<tva:Title>Filml</tva:Title> 

<tva : Synopsis length= " short " >A f ilm</tva : Synopsis> 

<tva: Genre href = "urn: tva: metadata : cs :ContentCS :2005:3.4.6"> 

<tva :Name>Action</tva :Name> 
</tva :Genre> 
</tva : BasicDescription> 
</tva : Programinf ormation> 
</tva : Programinf ormationTable> 
</tva : ProgramDescription> 
</tva:TVAMain> 

Example 4 is another example query and response using a get_Data request. The query requests all of the programmes 
broadcast by a particular service available over a 2 hour period. Although the Server performs the query across all 
possible data the required response data is restricted to only those tables requested, in this case the Programlnformation 
and ProgramLocation tables. An exception to this is that a Servicelnformation table is always returned if there is 
reference to a service in the response e.g. in the ProgramLocation table. 
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Example 4: Query For Programmes Over A Two Hour Period 

<QueryConstraints> 
<PredicateBag type="AND"> 

<BinaryPredicate f ieldID="tvaf : PublishedTime" f ieldValue="2006-ll-01T12 : 00 : OOZ" 
test= " great er_than_or_equal s " / > 

<BinaryPredicate fieldID="tvaf : PublishedTime" f ieldValue="2006-ll-01T14 :00 : OOZ" 
test="less_than_or_equals"/> 

<BinaryPredicate f ieldID="tvaf : ServiceURL" f ieldValue="dvb ://l.l.l.l"/> 

</PredicateBag> 
</QueryConstraints> 
<RequestedTables> 

<Table type= " Programinf ormat ionTable " / > 

<Table type= " ProgramLocat ionTable " / > 
</RequestedTables> 

Example 5: Query Response 

<tva iTVAMain xml : lang="eng" xmlns : tva="urn: tva : metadata : 2005" 
xmlns :xsi="http : //www.w3 . org/2 01/XMLSchema- instance" > 
<tva : ProgramDescription> 

<tva : Programinf ormationTable> 

<tva : Programinf ormat ion programId="crid: //124" > 
<tva : BasicDescription> 

<tva:Title>Titlel</tva:Title> 

<tva: Synopsis length= " short " >A f ilm</tva : Synopsis> 

<tva: Genre href = "urn: tva: metadata : cs : Content CS :2005:3.4.6"> 

<tva :Name>Action</tva :Name> 
</tva :Genre> 
</tva :BasicDescription> 
</tva : Programinf ormation> 

<tva : Programinf ormat ion programId="crid: //125" > 
<tva : BasicDescription> 

<tva:Title>Title2</tva:Title> 

<tva : Synopsis length= " short " >A Soap Opera</tva : Synopsis> 

<tva: Genre href = "urn: tva: metadata : cs :ContentCS :2005:3.4.2.1"> 

<tva :Name>Soap opera< /tva : Name > 
</tva :Genre> 
</tva :BasicDescription> 
</tva : Programinf ormation> 
</tva : Programinf ormationTable> 
<tva : ProgramLocationTable> 

<tva:Schedule servicelDRef ="servicel" start="2006-ll-01T00 : 00 : OOZ" end="2006-ll- 
01T23 :59:59Z"> 

<tva : ScheduleEvent> 

<tva: Program crid="crid: //124"/> 

<tva:PublishedStartTime>2aa6-ll-01T12 : 00 : OOZ</tva: PublishedStartTime> 
<tva : PublishedDuration>PT01H30M00S</tva : PublishedDuration> 
</tva : ScheduleEvent> 
<tva : ScheduleEvent> 

<tva : Program crid="crid: //125"/> 

<tva:PublishedStartTime>2006-ll-01T13 :30: OOZ</tva : PublishedStartTime> 
<tva : PublishedDuration>PT00H30M00S</tva : PublishedDuration> 
</tva : ScheduleEvent> 
</tva : Schedule> 
</tva : ProgramLocationTable> 
<tva : Serviceinf ormationTable> 

<tva : Serviceinf ormation serviceld="servicel"> 
<tva :Name>servicel</tva :Name> 

<tva:ServiceURL>dvb: //I .1.1. l</tva : ServiceURL> 
</tva : Serviceinf ormation> 
</tva : Serviceinf ormationTable> 
</tva : ProgramDescription> 
</tva:TVAMain> 
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Connection to the Content 



At this step, the HNED has collected the XML files that contains the content description (SD&S or BCG structures). 
The HNED can then connect to the content. This will involve different mechanisms whether the content is live 
broadcast or on-demand. 

5.1 Connection to Live Content 

Live content is typically described using SD&S metadata, but it can also be exposed using BCG metadata. 

5.1.1 Connection possibilities 

A Live TV service may be accessed by an individual HNED in the following ways: 

• Using IGMP (Internet Group Management Protocol): 

In this case, the HNED has collected a Multicast IP address for this Live TV service. To display this Live TV 
channel, the HNED sends an IGMP Report request to this Multicast IP address in order to subscribe to this 
multicast group. Multicast Content Services use IGMP version 3 with Source Specific Multicast. This allows 
significant scalability and implementers should note that the previous version of IGMP is not allowed 
(see clause 7.3 of TS 102 542-1 [9] for details). 

• Using RTSP (Real Time Streaming Protocol): 

In this case, the HNED has collected a RTSP URL for this Live TV service. This RTSP URL gives all the 
information necessary to issue the appropriate RTSP method. Parameters required for the IGMP message will 
be acquired via the SETUP method from RTSP. 

5.1 .2 Live Content exposed with BCG 

Within the BCG, the locator is carrying the connection information, be it multicast or RTSP. See [3], clause 8 for details 
on the locators defined for BCG. 

As an alternative, the ScheduledEventType.ProgramURL can carry such locator. In this case, note that the locator 
resolved from the CRID has to be considered as the most accurate locator for the service. 

5.2 Connection to Content on Demand 

Content on Demand shall be exposed thanks to the Broadband Content Guide. RTSP shall be used to access the content. 
As for the Live Content exposed by the BCG, the locator is carrying the connection information. See [3], clause 8 for 
details on the locators defined for BCG. 

As an alternative, the OnDemandProgramType.ProgramURL can carry such locator. In this case, note that the locator 
resolved from the CRID has to be considered as the most accurate locator for the service. 

5.3 RTSP Connection Management 
5.3.1 RTSP with BCG 

This clause will present call flows for RTSP session management as announced from the BCG metadata. The first 
example will be the simplest one, with only one RTSP address. The second example will involve EEC and RET flows 
that also need their own RTSP sessions. 
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5.3.1 .1 RTSP Session with one media flow 

The following service is announced via the BCG: 



<?xml version="l . 0" encoding="UTF-8" ?> 

<tva iTVAMain xml : lang="eng" xmlns : tva="urn: tva : metadata : 20 05" 
xmlns :xsi="http : //www.w3 . org/2 01/XMLSchema- instance" > 
<tva : ProgramDescription> 

<tva : Programinf ormationTable> 

<tva : Programinf ormat ion programId="crid: //cridauth. com/A" f ragmentld="10 0" > 
<tva : BasicDescription> 

<tva:Title>Sport Program l</tva :Title> 
<tva: Synopsis length= " short " > 

This is the synopsis of a sport programme 
</tva : Synopsis> 

<tva:Duration>P0DT01H30M</tva:Duration> 
</tva :BasicDescription> 
<tva : Attributes> 

<AudioAttributes> 

< Coding href =" urn: mpeg:mpeg7 : cs lAudioCodingFormatCS :2001:3.2"> 

<Name>MPEG-l Audio Layer II</Name> 
</Coding> 

<NumOf Channel s>2</NumOf Channel s> 
</AudioAttributes> 
<VideoAttributes> 

< Coding href =" urn: mpeg:mpeg7 : cs : VisualCodingFormatCS :2001:2.2.2"> 

<Name>MPEG-2 Video Main Profile @ Main Level</Name> 
</Coding> 
</VideoAttributes> 
</tva : Attributes> 
</tva : Programinf ormation> 
</tva : Programinf ormationTable> 
<tva : ProgramLocationTable> 
<tva : OnDemandProgram> 

<tva : Program crid="crid: //cridauth. com/A" /> 

<tva : ProgramURL>rtsp : //ondemand. provider 1 . com/movie</tva : ProgramURL> 
< / tva : OnDemandProgram> 
</tva : ProgramLocationTable> 
</tva : ProgramDescription> 
</tva:TVAMain> 

NOTE 1: The tva:ProgramLocationTable is carrying in this example the tva:ProgramURL, which is optional. This 
URL carries the direct link to the RTSP URL. This RTSP URL can also be retrieved by resolving the 
GRID (see clause 7), which is always considered as the most accurate locator information. 

The following shows an example of message exchange between the HNED and the RTSP server. At first, the HNED 
MUST send a RTSP DESCRIBE to retrieve information about the service. This RTSP DESCRIBE is useful because the 
TVA metadata available through the BCG do not carry any information on the transport layer of the content (if it is 
UDP or RTP, if there is EEC or retransmission available with the content). 



DESCRIBE rtsp: //ondemand. providerl .com/movie RTSP/1.0 

CSeq: 1 

Accept: text/xml 



The DESCRIBE response from the server includes an XML structure that is the CoDAnnounceDescribe XML structure. 

RTSP/1.0 200 OK 

Cseq: 1 

Content -length: 391 

Content-Type: text/xml 

Content -Encoding: UTF-8 

<?xml version="l . 0" encoding="UTF-8" ?> 

< CoDAnnounceDescribe 

xmlns="urn:dvb : ipisdns : 2006" 

xmlns :xsi=http : //www. w3 . org/2 01/XMLSchema- instance 

Streaming= " RTP " > 

<ContentDescription> 

<tva :Title>Sport Program l</tva :Title> 

<tva : Synopsis length= " short " > 

This is the synopsis of a sport programme 

</tva : Synopsis> 
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<tva:Duration>P0DT01H3 0M</tva:Duration> 
</ContentDescription> 
</CoDAnnounceDescribe> 



NOTE 2: In this example, there is no RTSPControlURL attribute since there is only one flow. The global RTSP 
URL is used for all messages (SETUP, PLAY . . .)• 

The HNED perform a SETUP for this service. In this example, only one SETUP is necessary since only one media flow 
is sent on the network (the MPEG2-TS stream). 



SETUP rtsp: //ondemand.providerl .com/movie RTSP/1.0 

CSeq: 2 

Transport : RTP/AVP ; unicast ; client_port = 8 8 88-8889 



RTSP/1.0 


200 OK 






























Cseq: 2 
































Session: 


12345678; 


timeout = 


60 


























Transport 


: RTP/AVP 


; unicast 


/client 


port = 


= 8888 


-8889 


source: 


= 67 


89 


12 


34 


server 


port = 


= 5502 


-5503 



Then the HNED sends the PLAY message to the server. 



PLAY rtsp : //ondemand.providerl . com/movie RTSP/1.0 

CSeq: 3 

Session: 12345678 



RTSP/1.0 


200 OK 




Cseq: 3 






Session: 


12345678 




RTP-Info 


url=rtsp : //ondemand.providerl . com/movie 


seq=1122 3 344;rtptime=102 3 04 



5.3.1 .2 RTSP Sessions with multiple media flows 

The following service is announced via the BCG: 



<?xml version="l . 0" encoding="UTF-8" ?> 

<tva :TVAMain xml : lang="eng" xmlns : tva="urn: tva : metadata : 2005" 
xmlns :xsi="http : //www.wS . org/2 01/XMLSchema- instance" > 
<tva : ProgramDescription> 

<tva : Programinf ormationTable> 

<tva : Programinf ormat ion programId="crid: //cridauth. com/A" f ragmentld="10 0" > 
<tva : BasicDescription> 

<tva:Title>Sport Program l</tva :Title> 
<tva : Synopsis length= " short " > 

This is the synopsis of a sport programme 
</tva : Synopsis> 

<tva:Duration>P0DT01H30M</tva:Duration> 
</tva :BasicDescription> 
<tva : Attributes> 

<AudioAttributes> 

< Coding href =" urn: mpeg:mpeg7 : cs :AudioCodingFormatCS :2001:3.2"> 

<Name>MPEG-l Audio Layer II</Name> 
</Coding> 

<NumOf Channel s>2</NumOf Channel s> 
</AudioAttributes> 
<VideoAttributes> 

< Coding href =" urn: mpeg:mpeg7 : cs : VisualCodingFormatCS :2001:2.2.2"> 

<Name>MPEG-2 Video Main Profile @ Main Level</Name> 
</Coding> 
</VideoAttributes> 
</tva : Attributes> 
</tva : Programinf ormation> 
</tva : Programinf ormationTable> 
<tva : ProgramLocationTable> 
<tva : OnDemandProgram> 

<tva : Program crid="crid: //cridauth. com/A" /> 

<tva : ProgramURL>rtsp : //ondemand.providerl . com/movie</tva : ProgramURL> 
< / tva : OnDemandProgram> 
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</tva : ProgramLocationTable> 
</tva : ProgramDescription> 
</tva:TVAMain> 



NOTE 1: The tva:ProgramLocationTable is carrying in this example the tva:ProgramURL, which is optional. This 
URL carries the direct link to the RTSP URL. This RTSP URL can also be retrieved by resolving the 
CRID (see clause 7), which is always considered as the most accurate locator information. 

The following shows an example of message exchange between the HNED and the RTSP server. At first, the HNED 
MUST send a RTSP DESCRIBE to retrieve information about the service. This RTSP DESCRIBE is useful because the 
TVA metadata available through the BCG do not carry any information on the transport layer of the content (if it is 
UDP or RTP, if there is EEC or retransmission available with the content). 



DESCRIBE rtsp: //ondemand.providerl .com/movie RTSP/1.0 

CSeq: 1 

Accept: text/xml 



The DESCRIBE response from the server includes an XML structure that is the CoDAnnounceDescribe XML structure. 



RTSP/1.0 200 OK 

Cseq: 1 

Content -length: 391 

Content-Type: text/xml 

Content -Encoding: UTF-8 

<?xml version="l . 0" encoding="UTF-8" ?> 
<CodAnnounceDescribe 
xmlns="urn:dvb : ipisdns : 2006" 

xmlns :xsi=http : //www. w3 . org/2 01/XMLSchema- instance 
Streaming= " RTP " 

RTSPControlURL="rtsp : //ondemand.providerl . com/movie ?Media" > 
<ContentDescription> 

<tva :Title>Sport Program l</tva :Title> 
<tva : Synopsis length= " short " > 

This is the synopsis of a sport programme 
</tva : Synopsis> 

<tva:Duration>P0DT01H3 0M</tva:Duration> 
</ContentDescription> 

<FECInfo FECMaxBlockSizePackets="8" FECMaxBlockSizeTime=" 100 " FEC0TI="MDBJMTA1MDE=" > 
<FECBaseLayer MaxBitrate="200" 

RTSPControlURL="rtsp : //ondemand.providerl . com/movie ?FecBase" /> 
<FECEnhancement Layer MaxBitrate="200" 

RTSPControlURL="rtsp : //ondemand.providerl . com/movie ?FecEnhancement" /> 
</FECInfo> 
</ CoDAnnounceDescribe > 



NOTE 2: In this example, there are some EEC layers available for the content. Thus some RTSPControlURL 
attributes are needed, since each flow (media, EEC) is setup separately. 

The HNED perform then several SETUP for this service: one SETUP is needed for each flow, i.e. one for the media 
flow (using the RTSPControlURL of the media flow), and one for each EEC layer (using the RTSPControlURL of the 
EEC layers). If the HNED does not want to connect to a flow, it will not issue the corresponding SETUP command. In 
this example, the HNED will only connect to the media flow and to the EEC Base layer. 



SETUP rtsp: //ondemand.providerl .com/movie?Media RTSP/1.0 

CSeq: 2 

Transport : RTP/AVP ; unicast ; client_port = 8 8 8 8-8889 



RTSP/1.0 


200 OK 






























Cseq: 2 
































Session: 


12345678; 


timeout = 


60 


























Transport : RTP/AVP 


; unicast 


/client 


port = 


= 8888 


-8889 


source= 


= 67 


89 


12 


34 


server 


port = 


= 5502 


-5503 



ETSI 



20 



ETSI TS 102 542-2 V1.3.1 (2010-01) 



SETUP rtsp: //ondemand.providerl .com/movie?FecBase RTSP/1.0 

CSeq: 3 

Session: 12345678 

Transport : RTP/AVP;unicast ;client_port=8890-8891 



RTSP/1.0 


200 OK 






























Cseq: 3 
































Session: 


12345678; 


timeout = 


60 


























Transport 


: RTP/AVP 


;unicast 


/client 


port = 


= 8890 


-8891 


source= 


= 67 


89 


12 


34 


server 


port = 


= 8210 


-8211 



Then the HNED sends the PLAY message to the server. Only one PLAY is needed for both flows. 



PLAY rtsp : //ondemand.providerl . com/movie RTSP/1.0 

CSeq: 4 

Session: 12345678 



RTSP/1.0 


200 OK 




Cseq: 4 






Session: 


12345678 




RTP-Info 


url=rtsp : //ondemand 


providerl . com/movie?Media; seq=11223 344 ;rtptime=102 3 04 , 


url=rtsp 


/ /ondemand . providerl 


com/movie?FecBase;seq=55 6 6 778 8;rtptime=50 6 70 8 



5.4 Transport of the stream 



The video content is streamed using an MPEG-2 transport stream, as defined in TS 101 154 [2], which is then 
encapsulated in RTP/UDP or directly in UDP. Usually a Single Program Transport Stream (SPTS) is used as only the 
bandwidth for the selected content is needed. However Multi Program Transport Streams (MPTS) are not out ruled. 

The information if RTP/UDP or UDP encapsulation is used is provided by the BCG locator for multicast services and 
by the RTSP transport header for unicast services: 

• A BCG locator with the syntax "rtp://. ..." indicates RTP/UDP encapsulation. 

• A BCG locator with the syntax "udp://...." indicates direct UDP encapsulation. 

A RTSP transport header of "RTP/AVP/UDP" indicates RTP/UDP encapsulation. A RTSP transport header of either 
"MP2T/H2221/UDP" or "RAW/RAW/UDP" indicates direct UDP encapsulation. 
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